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(54) Tide: SYSTEM AND METHOD FOR AUTHENTICATION OF NETWORK USERS AND ISSUING A DIGITAL CERTIFICATE 

(57) Abstract 

A network authentication 
system generates digital certificates 
to users (14-50), which provide 
verification of the identity or 
other attributes of the users to 
conduct a transaction, access 
data or avail themselves of other 
resources (14-50). The user is 
presented with a hierarchy of 
queries based on wallet-type (basic 
identification) and non-wallet type 
(more private) information designed 
to ensure the identity of the user 
and . prevent fraud, false negatives 
and other undesirable results 
(52-72). A preprocessing stage 
may be employed to ensure correct 
formatting of the input information 
and clean up routine mistakes (such 
as missing digits, typos, etc.) that 
might otherwise halt the transaction. 
The authenticator can be configured 
to require differing levels of input 
or award differing levels of privilege 
to the ultimate certificate (14-50). 
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SYSTEM AND METHOD FOR AUTHENTICATION 
OF NETWORK USERS AND ISSUING A DIGITAL CERTIFICATE 

Field of the Invention 
The invention relates to electronic communications, and more 
: 5 particularly to issuing digital certificates including those for authenticating the 
identity of network users. 

Background of the Invention 
The issuing of digital certificates to promote electronic commerce is 
known. Digital certificates, that is, specially issued files containing 

10 identification and other information, provide a level of security and 
authentication that gives vendors, suppliers and others comfort as they 
increasingly commit to electronic commerce. Digital certificates provide 
electronic confirmation of the identity of a potential customer or other user 
seeking to access a resource or to process a transaction. Digital certificates also 

15 regulate the access to particular transactions or information. For example, 
digit&l certificates can differentiate classes of transaction within a Web site 
based upon credit or other information contained in a digital certificate or 
directory. 

Typically, the steps involved in deciding whether to issue a digital 
20 certificate involve an interaction between a user who wants to perform a 
transaction and a certification authority. In most cases, the certification 
authority is not a party to the eventual transaction but serves instead to qualify 
the user to perform transactions by issuing a digital certificate. The certification 
authority queries the user for information and attempts to match the responses to 
25 known data from databases to determine whether to issue the digital certificate 
to the requesting user. In addition, the responses provided and the data available 
in the databases may be used by the certification authority to determine the 
content or privilege level of the digital certificate. That is, the certification 
authority determines what financial, privilege or other limitations will be 
30 associated with the digital certificate, as indicated by the criteria of the online 
vendor. 
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An important aspect of the process of issuing the digital certificate is 
confirming the identity of network users. Various systems exist that perform 
some level of user authentication. These systems generally require a user to 
provide certain basic identification information, such as name, date of birth, 
5 social security number, address, telephone number and sometimes driver's 
license information. This type of information is sometimes known as wallet 
information, and it is compared to known data, such as from a credit file to 
determine a level of match between the stored and presented information. 
However this type of validation by itself is limited and not flexible in accepting 
10 other types of background information. Other problems exist. 

Summary of the Invention 
It is an object of the invention to overcome these and other drawbacks of 
existing digital certificate systems and methods. 

It is another object of the invention to provide a digital certificate issuing 
15 system and method that perform a first authentication step based on a first type 
of user identification information and, based on the result, determine whether to 
perform at least a separate second authentication step using further information. 

Another object of the invention is to provide a digital certificate issuing 
system and method that perform a first authentication step based on a first type 
20 of user identification information and, based on the results of the first 
authentication step, determine whether to proceed to at least a second 
authentication step depending on available information and the level of certainty 
of authentication desired. 

Another object of the invention is to provide a digital certificate issuing 
25 system and method with a multilevel authentication process, where a first step 
includes the preprocessing of user-supplied information. 

It is still another object of the invention to provide a digital certificate 
issuing system and method which determine the content or privilege level of a 
digital certificate to be issued including, for example, the financial and access 
30 privileges or other classifications associated with the digital certificate. 
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In an illustrative embodiment of the invention, a user who wishes to 
apply for an online transaction accesses a client/server network through a client 
terminal. The server side of the network includes an application server 
communicating with an authentication server. When the user wishes to initiate 
5 the transaction or at other times, the authentication server determines whether 
the user's identity can be confirmed, and the level of authentication that may be 
accorded to the user's identity based on specific to the vendor accepting the 
transaction rules. 

The transaction the user is applying for, such as an electronic brokerage 
10 trade, is either carried out or not carried out or other action taken depending on 
the results of the authentication. The extent of authentication processing 
performed depends upon the nature of the transaction and vendor-specific 
requirements. Once the authentication process has been satisfied, the invention 
may generate a digital certificate recording authentication levels and other 
15 information related to the user. The digital certificate can then be presented in 
future transactions to avoid the need to reauthenticate the user for each new 
transaction event. 

For example, in the context of electronic commerce, lower risk 
transactions such as relatively small purchases may not require an extensive 

20 authentication process. On the other hand, more sensitive or greater risk 
transactions such as large purchases or sensitive data access may require a more 
thorough authentication process and a greater level of certainty. A greater level 
of security could conceivably be attained by automatically performing a 
thorough authentication process for every transaction. However, this approach 

25 incurs unnecessary costs or resources in cases where only a lower level of 
certainty is needed. 

The invention avoids this drawback by enabling different levels of 
authentication to be performed based on the level of security desired, reducing 
costs and unnecessary use of system resources. 

30 Generally in the invention, the user is authenticated according to their 

ability to respond to successive queries for personal information and the level of 
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match attained from comparing the information they provide with reliable data 
sources. The user is initially requested to provide a first type of identification 
information. The first type of information is preferably wallet-type information, 
that is, information such as name, address, driver's license or other information 
5 that may be commonly carried on the person. This information is transmitted to 
the authentication-server which carries out a first level authentication process on 
that information. 

That first level authentication process compares the degree of match 
between the user-supplied first type of information and known data about the 
10 user from other sources. At the completion of this first level authentication 
process, the authentication server may allow the requested access, allow the 
requested access with restriction, refuse access or proceed to another level of 
authentication. 

Preferably, the second and any additional levels of authentication request 
15 a second, non-wallet type of information from the user. The second type of 
information is preferably based on comparatively private information that only 
the user would know. For example, the second type of information may include 
mortgage loan or other information obtained from a credit report or another 
source. Such information is typically not carried with a person, and therefore 
20 the chances of fraud by someone who obtains lost or stolen information and 
attempts to execute a transaction are reduced. 

The private financial or other data elicited in the second level 
authentication process may be requested using an interactive query. The 
interactive query may include multiple choice questions that are automatically 
25 generated based upon the information available in the known data sources. For 
example, the authentication server may access a credit file to identify loans of 
the user which are still in payback status. One or more loans may be selected 
and the lender's name and corresponding monthly payment amount retrieved 
from the credit file. 

30 The interactive query might ask the user for the lender's name or 

payment amount on the identified loan and offer a number of choices for each of 
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the lender's name and the correct payment amount, only one of which is correct. 
Depending upon the responses, the user's identity may be authenticated fully, or 
to a greater or lower degree of certainty compared with that based solely on the 
first level authentication process. 
5 The invention may include a preprocessing stage executed before first or 

second level authentication. The preprocessing stage filters or corrects 
relatively minor mistakes in formatting and consistency in the user's responses, 
preserving the "transaction for fiirther processing and avoiding needless 
termination before the upper stages are reached. 
10 Brief Description of the Drawings 

Fig. 1 is a flowchart of an overall process for authenticating users 
according to the invention. 

Fig. 2 is a flowchart of an overall processing flow for authenticating 
users according to the invention in another aspect. 
15 Fig. 3 is a flowchart of certain aspects of second level authentication 

according to the invention. 

Fig. 4 is a flowchart of a preprocessing process according to the 
invention. 

Fig. 5 is a flowchart depicting a format verification process according to 
20 the invention. 

Fig. 6 is a flowchart depicting a standardization process according to the 
invention. 

Fig. 7 is a flowchart depicting a validity verification process according to 
the invention. 

25 Fig. 8 is a flowchart depicting a consistency verification process 

according to the invention. 

Fig. 9 illustrates an example of a verification matrix used in the 
invention. 

Fig. 10 illustrates an example of error codes that may be generated 
30 according to the invention. 
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Fig. 1 1 illustrates an example of a preprocessing matrix used in the 
invention. 

Fig. 12 illustrates a block diagram of an overall system according to the 
invention. 

5 Figs. 13-16 illustrate a transaction record generated according to the 

invention. 

Figs. 17 and 18 illustrate pattern recognition criteria used by the 
invention to detect irregularities. 

Fig. 19 illustrates potential action taken by the invention upon detection 
10 of pattern recognition criteria. 

Fig. 20 illustrates a scoring matrix for different types of accounts in 
second level authentication according to the invention. 

Fig. 21 illustrates a relative weighting of different types of queries used 
in second level authentication according to the invention. 
15 Fig. 22 illustrates a tiering of certainty scores into a set of categories 

according to the invention. 

Figs. 23-28 illustrate an assignment of overall certainty scores from first 
and second level authentication results generated according to the invention, 
from highest to lowest. 
20 Fig. 29 illustrates a tiering of authentication results for different types of 

source accounts according to the invention. 

Fig. 30 illustrates action thresholds for a set of different actions 
according to the invention. 

Figs. 31-33 illustrate preprocessing and first level authentication queries 
25 in an example authentication session according to the invention. 

Figs. 34-36 illustrate second level authentication queries in an example 
authentication session according to the invention. 

Figs. 37-40 illustrate queries used to issue a digital certificate according 
to the invention. 

30 Fig. 41 illustrates a digital certificate generated according to the 

invention. 
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Fig. 42 illustrates a remote authentication system according to the 
invention in which authentication is performed in an offline fashion. 

Fig. 43 illustrates the offline remote authentication embodiment of the 
invention operating when a social security number data field is supplied. 
5 Fig. 44 illustrates the offline remote authentication embodiment of the 

invention operating when a social security field is not supplied. 

Fig. 45 illustrates a block diagram of an overall system according to the 
invention, in another aspect. 

Detailed Description of Preferred Embodiments 

W The invention in general operates in a network environment and 

provides a system and method to authenticate a network user's identity using a 
hierarchy of information queries. The invention may draw on information from 
one or more data sources to execute the hierarchy of authentication stages, 
depending upon the transaction or data sensitivity. The invention may 

15 dynamically adjust the extent of authentication necessary, based upon preset 
thresholds or upon tests of input validity as the user supplies that information. 

A front-end preprocessing stage may serve to filter or correct erroneous 
information such as mistaken zip codes, missing digits or other matters of form 
so that the transaction may be preserved without needless termination before 

20 first or second level authentication. At the conclusion of the authentication 
process, the invention may issue a digital certificate to the user's machine to 
record authentication information, to present for later transactions or to update. 
An illustration of the overall architecture of the invention is in Fig. 45, and 
flowcharts of the overall processing flow are shown in Figs. 1 and 2. 

25 In terms of the network environment of the invention, in an embodiment 

illustrated in Fig. 12, client 1 10 communicates with application server 130 over 
a physical or wireless transmission link 150. Transmission link 150 may be a 
direct Internet connection or include the Internet as an intermediate segment. 
Transmission link 150 may include a dial-up Internet connection, dial-in server 

30 access, an intranet connection, a Tl or T3 digital line, an ISDN digital line, 
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LAN connection, a wide area network, Ethernet, DSL connection or other wired 
or wireless connection. 

In an Internet context, application server 1 30 preferably contains Internet 
server software (such as the publicly available Apache package or others) 
5 communicating with a browser application resident on client 1 10, which may be 
a personal computer or workstation running the Microsoft Windows™ 95 or 98 
operating systems, Internet access device such as a WebTV™ unit, or other 
hardware or software. 

The system includes an authentication server 120 on which the 

10 authentication process 10. of the invention is resident and executes. 
Authentication process 10 may be for instance implemented in programmed 
machine instructions, such as in C, C++, Java or other compiled, interpreted or 
other computer programming languages. In an alternative embodiment, 
authentication process 10 may be coresident on application server 130, 

15 obviating the need for authentication server 120. Authentication server 120 and 
application server 130 each may each be a workstation or personal computer, for 
instance running the Unix, Linux or Microsoft Windows™ NT™ operating 
systems or other hardware and software, and each may communicate with 
various databases to obtain user identification information for first and second 

20 level authentication. 

As illustrated in Fig. 12, such databases may include a credit database 
160, mail database 170, phone database 180 and one or more other databases 
190 which may be directly or indirectly accessible by or resident on 
authentication server 120 or application server 130. In addition, authorization 

25 database 152 is associated and communicates with authentication server 120. 
Authentication process 10 preferably receives and stores data to and from the 
authorization database 152, including transaction record 1 12 (illustrated in Figs. 
13-16) which logs user input, queries and other information as a temporary or 
permanent record. 

30 Fig. 12 also shows one or more resources 140 which are accessible to 

application server 130. These may include, for example, databases, other 
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computers, electronic memory, CD ROMs, RAID storage, tape or other archival 
storage, routers, terminals, and other peripherals and resources. 

According to the invention, a user who wants to access information or 
process a transaction over a network is prompted to submit information to 
5 authentication process 10 through client 110. Authentication process 10 
invokes the preprocessing step 26, in which the user is prompted to supply a 
first type of user identification information. The first type of user identification 
information preferably comprises wallet-type information such as name, 
address, phone number, social security number, driver's license number and 

10 other common personal information. 

This information is supplied to authentication process 10 via application 
server 130, in a standard application format, by client 110. In one aspect of the 
invention, application server 130 may be operated by an online vendor, such as 
a brokerage firm, merchandise retailer or other (see e.g. Fig. 45) and serves as a 

15 conduit between client 110 and authentication server 120 once authentication 
process 10 is invoked. It is possible however for client 1 10 and authentication 
server 120 to communicate the requested data directly without passing through 
application server 130. 

The user inputs the first type of information requested into client 110. 

20 Data may be queried from the user through textual questions, graphical user 
interfaces (GUIs), hyper text markup (HTML) forms or any other suitable 
mechanisms, either in a real-time interactive environment or through a batch 
submission. Selection of the input mode may depend upon various factors such 
as resource loading and availability, business model, user and system traffic and 

25 transaction criticality. 

Following the initialization of the transaction record 1 12, the association 
check 24 may be executed. Before entering the preprocessing step 26, the 
authentication process 10 may invoke association check 24 to evaluate whether 
the request under consideration is associated with other requests or attempts, 

30 whether recent, concurrent or otherwise. The purpose of the association checks 
is to filter requests suspected to be fraudulent or part of an attack of some kind. 
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Pattern recognition (illustrated in Figs. 17 and 18) may be used to identify 
requests which should be identified as having a fatal defect or potential for 
fraud, requiring immediate rejection of the request. 

In a preferred embodiment, authentication process 10 stores information 
received through all requests in the authorization database 152, which stores 
transaction record 112 logging all input received from the user. Using this 
information, association checks based upon available data are facilitated. For 
example, if one attempt at access includes a name and an associated social 
security number, a concurrent or later request with the same name but a different 
social security number may be denied or flagged for further authentication. 

Conversely, if the later request includes a different name but the 
previously submitted social security number, the request may also be denied or 
flagged for further authentication. Association checks can examine any data 
provided by the user before or during the preprocessing step 26. 

After association check 24, the preprocessing step 26 may execute at one 
or more of authentication client 110, authentication server 120 and application 
server 130. Preprocessing step 26 at client 1 10 may be effected through the use 
of, for example, the transmission of Java applets to client 1 10 or through other 
software resident or executing on client 110. Thus, although authentication 
process 10 is shown in Fig. 12 to be resident on authentication server 120, 
portions or all of authentication process 10 may be distributed elsewhere. 

One advantage of the preprocessing step 26 is that it processes as much 
of the requested data as possible before retrieving data from separately stored 
data sources such as credit files, which can be expensive in terms of processing 
resources, time and cost. Those separate data files may be accessible via the 
Internet or other networks, may be owned by separate entities and may involve a 
per-access charge. The preprocessing step 26 involves in one regard assuring 
that data formatting is consistent between the information supplied by the user 
and what is expected in the databases. 

Preprocessing step 26 thus helps to ensure that the supplied data is as 
accurate as possible to increase the likelihood of generating a match when the 
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user's identity is genuine. This reduces false negatives due to inconsistencies 
such as supplied nicknames instead of a full first name, contractions, missing 
titles, or mismatched formatting of social security numbers applied against 
known data sources. 

5 If the data supplied by the user is determined to be not feasible, 

incorrect, or otherwise clearly deficient before soliciting data from the separate 
data sources, it is still possible to proceed to those other data sources after the 
user input has been revised to meet the minimum requirements without 
interrupting the overall transaction. 

10 If the user does not respond to a request for a mandatory item of 

information (e.g., name) it is preferable to reprompt the user for that field before 
incurring any database charges or expending additional processing resources. 
Another example where interception in this manner is beneficial is when a user 
supplies a six digit social security number. In this case it is clear that the 

15 response is deficient and no match is possible in the social security number 
databases, so those databases should not be unnecessarily accessed. 

In a preferred embodiment, the preprocessing step 26 may perform one 
or more of the following validation checks. 

1) Standard Field Checks . To ascertain whether all required 
20 information fields are present and in the proper format and if not, reprompt for 

them or reformat them as necessary to proper form. 

2) Social Security Check . The input social security number is 
compared with one or more published social security number tables or 
processed using one or more algorithms to determine its validity. These tables 

25 may include such information as numbers reported as deceased or fraudulent. 

3) Address and Telephone Checks . The address and telephone 
number provided are verified for consistency (i.e., city, state, and zip code 
agree; area code agrees with state) and the user's address is standardized. 
Standardization allows for more accurate matching with other databases at later 

30 stages of authentication process 10. During the preprocessing step 26, rejection 
or flagging for additional authentication may occur as a result of mismatches. 
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4) Driver's License Validation Check . The input driver's license 
number is processed to verify that the number is valid for the state of issue. 
These algorithms may be obtained through departments of motor vehicles or 
otherwise. 

The following information is preferably prompted for (R being required, 
O being optional) by authentication process 10 during preprocessing step 26 and 
supplied by the user: 



10 



15 



20 



25 



Table 1 

DESCRIPTION 
Last Name 
First Name 
Middle Initial 
Suffix 

Maiden Name, if applicable 
Current Address (CA) 
At CA < 2 Years Indicator (Y/N) 
Former Address 

Optional 

Home Phone Number 

Area Code Change Indicator (Y/N) 

Home Phone Published Indicator (Y/N) 

Work Phone Number 

Gender 

Date of Birth 

Social Security Number 

Drivers License Indicator (Y/N) 



REO/OPT 

R 

R 

0 

0 

0 

R 

R 

R only if At CA < 2 Yeats 
Indicator is Y, otherwise 

R 
R 
R 
0 
R 
R 
R 
R 
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Drivers License Number (DL) 
Drivers License State of Issue 

5 

Mother's Maiden Name 

Year of High School Graduation 

Number of Siblings 

10 Email Address 



R only if DL Indicator set to 
Y, 

otherwise Optional 

R only if DL Indicator set to 

Y, otherwise Optional 

0 

0 

0, includes half and step 

siblings 

0 



Other, non-wallet information, which is used for subsequent levels of 
authentication, can be collected during preprocessing step 26 or deferred until a 
later phase of the authentication process 10. A user failing to supply this 
15 information during preprocessing step 26 may be reprompted for it, and 
processing may or may not continue in the event the user never supplies 
information designated as required. This information preferably includes: 

Table 2 

20 DESCRIPTION REO/OPT 

Name of Lender R, only if Second Level 

Authentication used 
Loan Account Number 0 
Loan Type Indicator R, only if Second Level 

25 Authentication used 

Monthly Payment Amount R, only if Second Level 

Authentication used 
Preprocessing step 26 may thus include a set of validation checks 
including standard field checks, social security number validation, address 
30 validation, area code validation, and driver's license validation and other 
preliminary data verification. It is preferable that preprocessing occur in the 
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order presented, in part due to data dependencies of later checks on the earlier 
ones. However, it will be understood that the order may be rearranged, and 
different preprocessing checks may be employed. The enumerated validation 
checks are discussed in more detail in order below. 
5 First, standard field checks preferably occur at client 1 10, where and 

when the requested data is collected, to ensure that all required data is present 
and all provided data is in the proper format and meets minimum requirements. 
Completing this processing at client 1 10 minimizes the number of requests that 
must be terminated at this early point in the authentication process due to 

10 formally incorrect data. This is particularly important when the user is not 
present at the time of authentication, such as when requests are submitted in 
batch form rather than interactively. In general, the standard field checks make 
sure that an expected range or format of characters are input by the user, 
appropriate to individual queries and data types. 

15 The following is preferably accomplished during standard field checks: 

1) All required fields must be present. 

2) All provided fields must be in the proper format. 

First name must have at least one letter provided. 
Phone numbers must have 1 0 digits. 
Social security number must have 9 digits. 
Social security number must not have all 9 digits the 
same. 

Social security number's first 3 digits must not be equal to 
000. 

Social security number's 4 th and 5 th digits must not be 
equal to 00. 

• Social security number's last 4 digits must not be equal to 0000. 



20 



25 
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3) Specified fields must meet additional requirements. 

Age, derived from date of birth, must be 1 8 years old or 
older (However, a telephone number and drivers license 
may still be verified, even if a credit file is not available). 
5 Email address must contain an @ sign and a ".com" or 

other domain. 

The user is preferably afforded up to two additional attempts to correct 
any fields that do not meet the standard field check requirements. If any field 
cannot be corrected after a total of three attempts, the authentication process 1 0 
10 is preferably aborted. If the request has been successfully completed as 
determined by the standard field check portion of preprocessing step 26, the 
request may continue to the next preprocessing check. 

At that next stage of standard field checks, the social security number 
may be checked for some or all of the following: 

15 

Social security number contains 9 digits 

Social security number * 000000000, 11111111, 999999999. 

Social security number first 3 digits * 000 

Social security number 4th and 5th digits * 00 

20 Social security number last 4 digits * 0000 

Social security number does not match any social security 
number found on the Social security number fraud table. 
Social security number is in the issued range as determined by a 
lookup on the social security number range table. 

25 • Date of birth agrees with the social security number issue dates. 

The check against the published social security number fraud table is 
used to ensure that the supplied social security number is not listed as 
fraudulent. Such a table may be obtained from any of a number of sources 
30 including, for example, credit reporting companies or law enforcement agencies. 
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The social security number range table is used to ensure that the supplied social 
security number is not an invalid number. Such a table may be obtained from 
any of a number of sources including, for example, governmental agencies. 

Once it has been determined that the social security number has been 
5 issued, and a range of issue dates is known, the date of birth provided on the 
request can be compared to the date range for consistency. It is thus possible to 
perform another check to ensure that the social security number is valid based 
upon date of birth information. 

The user is preferably given only one additional attempt to correct social 
10 security number information that has been rejected by social security number 
validation checking. If the social security number cannot be accepted after a 
total of two tries, authentication process 10 is preferably aborted. 

Next, the validity of address information is confirmed, preferably using 
an address correction and standardization package (such as the PostalSoft 
15 package available from First Logic Corp.). For current address, and former 
address if provided, the package may: 

Verify that the city ? state and zip code agree. If only a city 
and state are provided, the package may be able to add the 
zip code. If only a zip code is provided, the package usually 
20 can add the city and state. 

Standardize the address line. The package can correct 
misspelled street names, fill in missing information and 
strip out unnecessary punctuation marks and spaces. 

Identify undeliverable addresses vacant lots, 

. 25 condemned buildings, etc.). 

Create a status code that tells how an input address had to 
be corrected. 

Create an error code that tells why an input address could 
not be matched, or assigned. 
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Responses, or actions, for each of the possible address-related status 
codes or error codes in error code matrix 156 (illustrated in Figs. 9-11) are 
provided as output during the preprocessing step 26. The user is preferably 
given only one additional attempt to correct each address that has been rejected 

5 by address validation. If the address cannot be corrected after a total of two 
attempts, the request proceeds as designated in the response matrix 154 
illustrated in Figs. 9-11. The response matrix 154 may be located on 
authentication server 120, in authorization database 152 or elsewhere and serve 
to associate messages with test results and transaction records during the 

10 address portion of preprocessing step 26, concurrently with overall application 
processing. 

In other words, the response matrix 154 sends messages to client 110 
based upon specific verification tests or based upon the current status of the 
transaction record 112. For example, the message may prompt the user to verify 

15 that data which was input is correct or a message to direct the user to call 
customer service for manual intervention. The response matrix 154 is 
preferably parameter driven, so that appropriate messages can be associated 
with particular events. 

The area code for the home phone number is preferably checked to 

20 determine if it is valid for the state supplied in the current address, in 
preprocessing step 26. The area code and state provided in connection with the 
request are compared with an entry for the area code in an area code table, 
available from database and other sources. The area code table contains area 
code information for each of the area code locations in the geographic area 

25 being served. 

The database for the area code and associated information may be 
preferably implemented, for example, using the commercially available 
MetroNet package. The phone number database information may be stored in 
phone database 180 connected to authentication server 120, or otherwise. The 

30 consistency of area code to state of residence may, for instance, be checked. 
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The user is preferably given only one additional attempt to correct home 
phone number information that has been rejected by the area code validation 
check. After the home phone number has been accepted or after a total of two 
tries, the process indicates the result, valid or not valid, in the transaction record 
5 112 and proceeds. 

Next, the drivers license number is checked to ensure that the format of 
the number is consistent with the format for the state of issue. An algorithm 
may look up the state of issue and compare the driver's license number provided 
in the request with the accepted format for the state. The user is preferably 

10 given only one additional attempt to correct driver's license number information 
that has been rejected by the driver's license check (or may be terminated 
immediately, according to vendor preference). After the driver's license number 
has been accepted or after a total of two tries, the authentication process 10 
indicates the result, valid or not valid, in the transaction record 112 and 

15 proceeds. 

In the event the user will be paying for a product or service with a credit 
card, authentication process 10 may invoke credit card verification at this point. 
In this case, checks may be executed against a credit card database. These 
checks may include ensuring that the available credit line is sufficient to make 

20 the purchase, ensuring that the billing address for the credit card in the database 
matches the submitted address, and ensuring that the credit card is not stolen. 
Databases presenting this sort of information are commercially available. 

Preprocessing step 26 thus may include internal corrections as well as 
comparisons of user-supplied data to known data which may be obtained from 

25 separate sources. Those sources may be third party databases such as 
commercial or government databases, or internal databases. Preferably, 
however, preprocessing step 26 is limited to checking user-supplied data against 
wallet-type data which is relatively conveniently, and locally, accessed. 
Preprocessing step 26 consequently offers increased certainty of authentication 

30 by using additional databases and requiring internal consistency as a predicate to 
first and second level authentication. 
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In conjunction with the checks carried out by preprocessing step 26, 
credit database 160 may be any suitable consumer credit history database 
available from various sources including credit reporting companies such as 
Equifax™. Mail database 170 and phone database 180 may be any suitable 
5 databases providing address and telephone information for the relevant 
geographic area (e.g., MetroMail which is a compendium of regional Bell 
operating company-supplied information). Other databases 190 may include, 
for example, a check services drivers license database which provides 
information concerning check validity. Any commercially available or internal 

10 database or others may be employed in processing the verification substeps of 
the preprocessing step 26. 

Additionally, the checks of preprocessing step 26 may include the use of 
a credit card application fraud model, or some other model which statistically 
analyzes response data. For example, the data supplied by the user may be 

15 modeled and graded for confidence level based upon empirical models supplied 
by third party vendors or available internally. An illustration of pattern 
recognition criteria that may be employed in this regard by the invention is 
illustrated in Figs. 17 and 18. As illustrated in those figures, in general the 
invention monitors user input recorded in transaction record 1 12 or otherwise 

20 for repetitive attempts at authentication, which may represent attempted fraud or 
some type of network attack. 

In such instances, and as illustrated in pattern recognition criteria matrix 
904 shown in Fig. 17, the input may include valid portions of information such 
as a social security number but varying unsuccessful attempts to find valid input 

25 for other fields. At any time during authentication process 10, the invention 
, may preempt the authentication event and terminate the session when pattern 
recognition senses a significant probability of irregularity. Different responses 
to different types of detected potential fraudulent transactions are shown in the 
pattern recognition match action matrix 912 of Fig. 19. As illustrated in the 

30 figure, different types of inconsistencies may result in different actions, 
including the locking out of suspected fraudulent entries for such patterns as the 
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same name under varying email addresses. Other inconsistencies may result in 
the starting of the authentication process 10 over again (QILT entries) at user 
request. 

In a preferred embodiment of the invention, the data supplied by the user 
5 must match a record from at least two data sources to graduate from the 
preprocessing step 26. This increases the level of certainty that the user's 
identity is genuine before graduating from that stage. Matching routines, 
implemented for each data source and type of check, compare query data to 
known source data and preferably assign a value to every match instance. This 

10 value may be termed an authenticity certainty score. An authenticity certainty 
score may be accumulated based upon the collective values assigned for each 
match instance of preprocessing step 26. The authenticity certainty score may 
be employed and compared against predetermined thresholds to determine the 
next action for the request (/>., approve, approve with restrictions, deny, go to 

15 first or other level preprocessing). 

If the data provided by the user does not meet the requirements of some 
or all of the checks of preprocessing step 26, a message may be returned to the 
user via link 150 requesting the data in question be corrected and resubmitted. 
Upon resubmission, the input data will again be analyzed. Alternatively, 

20 authentication process 10 may be preconfigured to immediately reject a request 
based upon a failure to satisfy a minimum level during preprocessing step 26. 

If the request is identified as a result of the association check 24 or other 
analysis as possibly fraudulent using the association check or otherwise, a 
message may be returned to client 110 indicating that the request cannot be 

25 processed automatically and that manual processing such as calling customer 
service is necessary. 

Biometric data may be employed either alone or in combination with the 
above preprocessing as well as subsequent authentication levels to ensure the 
identity of a user. That biometric data may include, for example, fingerprint 

30 information from the user, captured in analog or digital form, for instance, via 
an imprint peripheral connected to client 110. Biometric data may also include 
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infrared or other retinal or iris scans, or finger or hand geometry matches. 
Likewise, biometric data used by the invention may also include handwriting 
recognition, voice recognition using digitized sampling or other means or facial 
recognition input from video or other devices. 
5 The biometric data may also include DNA database matching. In 

general, any biometric technology now existing or developed in the future may 
be incorporated in the invention. The biometric data may be used as input fields 
or records in the preprocessing, first or second authentication level stages. 
Alternatively, biometric data may be used as a key to unlock and release a 

10 digital certificate 902 issued to the user, to be stored on client 1 1 0 or otherwise. 

Fig. 1 is a flowchart illustrating the overall authentication process 
according to the invention. Authentication process 10 starts at step 12. The 
authentication process 10 prompts a user for first level information at step 14. 
Again, the first type of information is preferably wallet-type information, that is, 

15 information such as name, address, driver's license or other information 
commonly carried on the person. The user inputs that first level information via 
a keyboard, mouse, voice digitizer or other suitable input mechanism at step 16. 
Step 18 identifies that the user has completed first level information input. Step 
20 transmits the input. The transaction record 1 12 is initialized at step 22. 

20 Step 24 performs an association check on the information input by the 

user. Authentication process 10 may then invoke the preprocessing step 26 
discussed above. If preprocessing step 26 is included, step 28 may also be 
provided, which determines whether preprocessing step 26 is complete. If 
preprocessing step 26 is not complete, authentication process 10 may return to 

25 step 14 to prompt the user for omitted, corrected or additional information, 
return to step 16 to allow the user to input information, or end authentication 
process at step 30. If preprocessing step 26 is complete, authentication process 
10 proceeds to step 32 of first level authentication. 

Authentication process 10 matches, at step 32, the first type of 

30 information input by the user with information received from one or more 
separate data sources. Based on that comparison, authentication process 10 
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determines whether the first level authentication is complete at step 34. If the 
first level authentication is not complete, authentication process 10 may return 
to step 14 to prompt the user for omitted, corrected or additional information, 
return to step 16 to allow the user to input information, or end authentication 
5 process at step 36. 

If the first level authentication is complete, authentication process 10 
determines at step 38 whether the user should be authenticated. If the user has 
not been rejected outright but has not yet been authenticated, authentication 
process 10 proceeds to step 40, second level authentication. Step 40 request and 

10 tests the user's input of a second type of information, which is preferably non- 
wallet type information. 

Authentication process 10 determines whether a request for information 
has been repeated more than a predetermined number of times at step 42. If the 
attempt exceeds the predetermined limit, authentication process 10 ends at step 

15 44. If the attempt does not exceed the predetermined limit, authentication 
process 10 determines whether step 40 is complete at step 46. If step 40 is 
complete, authentication process 10 renders an authentication decision at step 
48, then ends at step 50. If step 40 is not complete, authentication process may 
return to step 3 8 or end at step 47. 

20 Fig. 2 is a flowchart illustrating the process of the first level 

authentication step 32 in more detail. First level authentication process 32 
initiates at first level comparing step 52. The first level comparing step 52 
compares the information input by the user with information about the user 
retrieved from one or more known data sources. The user may be queried in the 

25 first level authentication step 32 for similar information to that accepted during 
the preprocessing step 26, or for refined or additional information. During 
processing of any user-input phone number information in the first level 
authentication step 32 after preprocessing step 26 (but preferably not in 
preprocessing step 26 itself), if the user indicates that they have been at the 

30 home telephone number for less than four months, the home telephone number 
and related source information may be preferably further checked against an 
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electronic directory assistance source, for better currency as compared to an 
offline database. During processing of any user-input driver's license 
information in the first level authentication step 32 (but preferably not in 
preprocessing step 26)^ any further checks against the driver's license database 
5 may be preferably implemented, for example, using the commercially available 
ChoicePoint drivers license database. Information from that external database is 
generally derived from official department of motor vehicle records or insurance 
claims information, the content of which may vary by state of issue. Step 54 
assigns values and priorities to each response input by the user. Information 

10 that is of greater significance may be assigned a higher value or priority. 

The transaction record 112 (illustrated in Figs. 13-16) initialized in step 
22 is used throughout the authentication process 10 to keep track of user input 
and authentication results. After the appropriate queries have been processed 
and all results stored in the transaction record 1 12, the transaction record 1 12 is 

15 used to determine an authentication score with respect to the request. Step 56 
calculates the total authentication score, and optionally, a score for each data 
source, data field, etc. The results are categorized as a big hit (B), a regular hit 
(R), a possible hit (P), or no hit (N) depending on results. Those results may 
then be combined with the results of second level authentication process 40 to 

20 determine an overall authenticity certainty score, as illustrated in Figs. 23-28 
and discussed below. 

Authentication process 10 determines whether one or more of the 
authentication scores is greater than or equal to a predetermined authentication 
value or threshold at step 58. If the authentication scores are greater than or 

25 equal to the predetermined authentication value, authentication process 10 
renders an authentication decision at step 60 and then ends at step 62. 

If one or more of the scores are less than their corresponding 
predetermined authentication value, authentication process 10 determines 
whether the level of certainty meets a predetermined certainty level at step 64. 

30 If the level of certainty is below the predetermined certainty level, 
authentication process 10 ends at step 66. Otherwise, authentication process 10 
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determines whether corrected or additional first type information is needed at 
step 68. If no other information is needed, authentication proceeds to step 40, 
second level authentication. If user input information needs to be revised, 
authentication process 10 may return to step 14 or step 16. 
5 Figs. 31-33 illustrate a set of queries associated with preprocessing step 

26 and first level authentication 32 in an example authentication session 
according to the invention. As can be seen in the figures, these phases of the 
invention query for and process wallet-type information to reach a first level of 
confidence about the genuineness of the user's identity. 

10 Fig- 3 is a flowchart illustrating the second level authentication process 

40 in more detail. Second level authentication process 40 begins with step 310. 
Step 310 accesses available second type information from data sources, such as 
a credit file. Step 312 prompts the user for second type information from within 
that determined to be available in step 310. Step 314 determines whether the 

15 user input matches the accessed information. 

In the execution of second level authentication process 40, 
authentication server 120 may access credit database 160. Credit database 160 
may be preferably implemented, for example, using a commercially available 
Equifax™ consumer credit file, in the ACRO file format. 

20 Inquiries may be transmitted back and forth between application server 

130 and authentication server 120 during second level authentication process, 
using the System-to-System 93 (STS) inquiry format for these types of data 
files, as will be appreciated by persons skilled in the art Credit line information 
returned from credit database 160 may be in System-to-System file fixed format 

25 (FFF), consistent with the ACRO file configuration. Second level 
authentication process 40 executes the search against credit database 160 to 
match the user's input against data in that file. 

The search maybe carried out according to the ACRO L90 search 
format, with results again categorized as a big hit (B), a regular hit (R), a 

30 possible hit (P), or no hit (N) depending on results, which in one embodiment 
are returned to authentication server 120 starting in ACRO header segment 
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position 285 in a 13 byte segment. Matches or no matches are returned as 
logical flags within that header segment. 

If the information matches, authentication process 10 either provides a 
higher degree authentication in step 316 or issues another degree of 
5 authentication in step 318. If the information does not match, authentication 
process 10 may issue a lower degree authentication, return to step 312 or end at 
step 324. 

An example of point scoring used in second level authentication 
according to the invention is illustrated in Figs. 20 and 21. The scoring matrix 

10 906 of Fig. 20 includes a set of point values for point values related to trade line 
accounts which the user may have, on a sliding scale according to the relative 
degree of significance of various accounts. In general, and as indicated in the 
relative weight matrix of Fig. 21, the proper identification of a lender name is 
given greater weight compared to monthly payment amount or terms of account 

15 data. 

In Fig. 22, the resulting certainty scores are ranked according to four 
categories of big hit (B), regular hit (R), probable hit (P), and no hit (N). 
Different combinations of accounts may lead to different maximum scores, 
according to the reliability or significance of the accounts available for second 

20 level authentication step 40. 

Upon completion of both the first level authentication step 32 and 
second level authentication step 40, results of all checking may be assembled to 
determine an overall authenticity certainty score, values for which are illustrated 
in the overall certainty scoring matrix 918 of Figs. 23-28. In general in those 

25 figures, big hits on credit file (second level authentication) checks contribute to 
higher overall certainty scores, which are normalized to 0 to 100. However, 
preferably no single check qualifies or disqualifies a user from authentication. 

Rather, according to the invention the aggregate weighting of all the 
user's response is factored into a variety of possible score ranges, depending on 

30 how highly the information they supplied correlates to the entire collection of 
data sources used by the invention. The scoring levels may be aggregated as 
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shown in the assignment matrix 920 of Fig. 29 to develop a tiered categorization 
(B, R, P, N) for all levels of authentication, and generate responses according to 
threshold table 922 as illustrated in Fig. 30. While particular numerical levels 
are shown in those matrices, it will be appreciated that the different scores and 
5 tiers are selectable or scalable according to application needs, in the invention. 

Figs. 34-36 illustrate a set of queries in screen shot form associated with 
second level authentication step 40 in an example authentication session 
according to the invention. In general, at this stage the authentication process 
10 identifies and accesses trade (credit) line information to query for data of a 
10 specific and private nature, which enhances the security profile of the user. In 
the example shown, both credit and merchant or trade line accounts are queried 
for lender identity and amounts. Accurate identification results in 
authentication, followed by issuance of a digital certificate 902 as desired. 

The system and method of the invention are customizable to allow a 
15 vendor operating an authenticating server 120 to set various parameters, 
including the thresholds or predetermined levels at different points of 
authentication process 10. If the predetermined authentication or certainty level 
has not been reached for a particular data source or data field, the user may not 
be eligible for authentication, or a higher degree of authentication. 
20 If a user successfully completes preprocessing, first and second 

authentication, in one embodiment the invention may issue a digital certificate 
902 to the user, as illustrated in Figs. 37-41. As illustrated in Figs. 37-40, after 
an indication of successful authentication the user is directed to input 
identification and challenge or password information to generate and store 
25 digital certificate 902. The digital certificate 902 contains a set of fields 
including user identification, a digital certificate serial number, an expiration 
period, as well as information related to the issuer of the digital certificate and 
fingerprint data for the digital certificate. 

The digital certificate 902 may be preferably stored in secure fashion on 
30 client 110, that is, protected by user identification and challenge or password 
queries before the recipient can release the digital certificate 902 for further 
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transactions, as illustrated in Figs. 37 and 38. Digital certificate 902 may be a 
data file stored in common machine readable format that upon proper release by 
the user can be presented to other authentication servers for later transactions, as 
evidence of identity and avoiding the need to reauthenticate the user for later 
5 events. As illustrated, digital certificate 902 contains an expiration field, but the 
certificate can be generated to persist indefinitely. 

Digital certificate 902 may be updated using a full or abbreviated 
authentication process 10 according to the invention, according to the grade of 
security required for particular future transactions. For example, a digital 

10 certificate 902 may be issued recording a medium grade of confidence of the 
user's identity, but to execute a sensitive transaction, the user may need to 
update and upgrade the digital certificate 902 to perform that later transaction. 

Although illustrated with two levels of authentication processing, it will 
be understood that the invention contemplates three or more levels of 

15 authentication performing additional checks using additional databases or 
prompting the user for more information, when appropriate to transaction 
requirements. Any of the levels of the authentication process 10 may be 
implemented via an interactive query format, e.g., using a multiple choice 
check-off box. At no time during presentation of the interactive query is the 

20 user presented with potential answers revealing only correct information, so that 
identification information cannot be captured simply by entering authentication 
process 10. Moreover, in the implementation of the invention it is possible to 
follow the entire authentication process 10 with a consumer profiling step, in 
which the now-authenticated user identity is associated with purchase, travel, 

25 geographic and other information to enable more highly targeted marketing or 
transaction activity. 

In general, in the execution of the authentication process 10 of the 
invention, answers to the interactive query questions are given highest relative 
weighting, followed by authentication checks against a user's credit file, 

30 followed by telephone information and then driver's license information. 
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As shown in Fig. 4 and described above, the preprocessing step 26 may 
be conducted before the hierarchy of authentication levels and include several 
preliminary procedures, mainly designed to ensure consistency in format. 
Discussion will return to preprocessing step 26 to describe the preprocessing 
5 stage in more detail in conjunction with Figs. 5-8. It will be understood that 
various combinations of standardization 400, formatting verification 410, 
verifying consistency 420, and verifying data validity 430 may be incorporated 
into the preprocessing step 26. As illustrated in Fig. 1, after preprocessing step 
26 is executed a decision 28 is made whether authentication should proceed. 

10 The decision 28 may result in a return to initial step 14 or an end to the 
- automated authentication process 10 at step 30. 

If preprocessing step 26 includes a formatting verification 410, the 
following process may be followed. The user input data is checked at step 500 
to determine that it is properly formatted. For example, the data may be 

15 checked to verify that the required fields have been entered (e.g., user name) or 
that the proper number of characters have been entered (e.g., nine digits for a 
social security number). If the result of the decision 500 is that the data is not in 
the proper form, a determination is made at step 510 whether the user has been 
prompted for this information previously. 

20 The authentication process 10 may be configured to allow a 

predetermined number of chances for the user to input data in the correct 
format. If the number of attempts exceeds the predetermined number, the 
process may terminate at step 520. If the predetermined number of chances has 
not been exceeded, the user may be prompted to input the data in the correct 

25 format at step 530. If the data is in the correct format, the process proceeds to 
step 540. 

Fig. 6 depicts the process for standardization 400 of the data. At step 
600 a determination is made whether the data is in the proper standard form. 
For example, the user's postal address may be checked for misspelled street 
30 names, or unnecessary punctuation. If the determination 600 finds the data to be 
non-standard, a determination 610 is made whether the non-standard data can be 
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corrected. If the data can be corrected, it may be accomplished at step 620 by 
internal or other processes. If the data cannot be corrected, a determination is 
made at step 630 whether the user has been prompted for this information 
previously. 

5 The authentication process may be configured to allow a predetermined 

number of chances for the user to input data in the correct format. If the number 
of attempts exceeds the predetermined number, the process may terminate at 
step 640. If the predetermined number of chances has not been exceeded, the 
user may be prompted to input standard data at step 650. If the data is in 

10 standard form, the process proceeds to the step 660. 

Fig. 7 depicts the process for determining the validity 430 of the data. 
For example, the validity may be verified by determining at step 700 whether 
the data is valid (e.g., does the social security number match any social security 
number found on the published deceased or fraudulent table). If the 

15 determination is made that the data is invalid, a determination 710 is made at 
step 710 whether the user has been prompted for this information previously. If 
the number of attempts exceeds the predetermined number, the process may 
update the transaction record at step 720 to reflect the presence of the invalid 
data. 

20 After the transaction record 112 is updated in step 720, an additional 

determination is made at step 730 of whether the process can proceed with this 
invalid data. If not, the process may terminate at step 740. If it can, the process 
may proceed to step 750. If the predetermined number of chances has not been 
exceeded, the user may be prompted to input valid data at step 760. If the data 

25 is valid, the process proceeds to step 750. 

A similar process may be followed to determine whether the data is 
consistent at step 420, as illustrated in Fig. 8. In step 760, the determination is . 
made whether the data from separate field entries are consistent. For example, 
data may be checked to verify that the area code entered matches the zip code 

30 entered. If the determination is made that the data entered by the user is not 
consistent, a determination is made at step 770 whether the user has been 
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prompted for this information previously. If the number of attempts exceeds the 
predetermined number, the process may update the transaction record 112 in 
step 780 to reflect the presence of the inconsistent data- 
After the transaction record 112 is updated 780, an additional 
5 determination is made at step 790 of whether the process can proceed with this 
inconsistent data. If not, the process may terminate at step 800. If it can, the 
process may proceed to step 810. If the predetermined number of chances has 
not been exceeded, the user may be prompted to input valid data at step 820. If 
the data is valid, the process proceeds to step 810 and the next preprocessing 
10 check. 

Figs. 9-11 show an example of the use of a matrix to verify address 
information in processing validity 430 or consistency 420. As shown, the 
verification process, which may be implemented using the commercially 
available PostalSoft, generates a matrix of address values to determine certain 

15 address information. Fig. 10 shows an example of certain error codes which 
may be generated to prompt user responses according to PostalSoft format when 
entered values, such as zip code, are not in proper format. Fig. 1 1 shows an 
example of certain actions and messages according to other types of data entered 
during processing for consistency 420. 

20 Generally speaking, there are several ways to administer the queries at 

the various levels of authentication of the invention, depending upon the 
requirements of the transaction. If the user is available at the time of application 
for an interactive dialog Internet request), a multiple choice questionnaire 
is preferably dynamically created by authentication process 10 and presented to 

25 the user, through client 1 1 0, for completion. 

Multiple choice alternatives for each question are preferably selected 
based upon the regional biases of the user, if applicable, and are designed to 
make it difficult for a fraudulent applicant to correctly guess the answers. That 
is, potential selections for various credit line or merchant account providers are 

30 provided in the same general geographic region as the user's home address, so 
that credit line account vendors are not obviously wrong based on location. The 
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user points and clicks on their selections, or provides answers in some other 
suitable way. The user-supplied answers jire then returned to authentication 
process 1 0 by client 1 10 for automated evaluation. 

If the user is not present at the time of application {e.g., batch 
5 submission), the information required to administer validation is provided on 
the initial application. If the user supplies account numbers, second level 
authentication step 40 will attempt to make the comparisons automatically. 
However, if the comparisons cannot be made automatically or the account 
numbers are not provided, the comparisons may be accomplished manually 

10 through human intervention. The results are returned to second level 
authentication step 40 for final evaluation. 

Fig. 18 illustrates an example authentication carried out according to 
authentication process 10 of the invention. In general, as illustrated in that 
figure, the user presents name, social security number, date of birth, email and 

15 mailing address information, followed by home telephone number and driver's 
license data. That information is accepted and processed through preprocessing 
step 26 and first level authentication step 32, after which it is determined that 
the data are consistent and merit proceeding to second level authentication step 
40. 

20 In second level authentication step 40, a sequence of questions are 

presented in an interactive query directed to mortgage account information, 
requesting lender and amount information followed by other merchant account 
information. Following successful authentication, the user is asked whether 
they wish to generate digital certificate 902, which is generated recording the 

25 successful authentication and protecting the digital certificate 902 by way of 
identification and challenge question data. 

Any or all of the processing steps described above can be invoked 
selectively or rearranged to constitute a complete authentication process 10. 
The requirements of the transaction will determine which processes to combine 

30 for particular authentication needs. It is possible to configure several different 
implementations as standard offerings. The vendor employing the 
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authentication system (vendor) can either use these standard offerings, or 
customize a configuration to their needs. With any implementation, the 
invention allows flexibility in determining certainty of authenticity, either 
through process configuration or setting certainty thresholds. 
5 In the practice of the invention, in the event of temporary downtime or 

other unavailability of any of the data sources used for comparison, the 
invention may revert to a backup source for that particular type of information 
(which may be generally consistent but not as current), substitute another data 
source, or take other action. 

10 Fig. 42 illustrates an offline remote authentication embodiment of the 

invention, in which some processing including delivery of a validated ID is 
conducted using ordinary mail. As illustrated in Fig. 42, in this embodiment, a 
remote authentication system 1002 controls two processing objects, a remote 
authentication object with a social security number field 1004, and a remote 

15 authentication object without a social security number field 1006. The remote 
authentication system 1002 invokes the remote authentication object 1004 when 
a user has presented a social security number, in an online application for a 
credit or other transaction. The remote authentication object 1004 may invoke 
the preprocessing step 26, to process standard field checks as in the other 

20 embodiments above. In this embodiment, in part because of the requirements 
for mail delivery, failure of one or more data fields for address standardization, 
such as zip code errors, blank fields, foreign addresses, and undeliverables may 
result in a failure state 1018. The failure state 1018 may also be reached when 
age is less than a predetermined level, or standard social security checks as 

25 described above are not met. Other factors which may result in a failure state 
1018 include mismatches concerning telephone numbers, social security 
numbers and fraud victim indicators present in a credit file. 

If the remote authentication object 1004 determines that the user has 
achieved a sufficient score during preprocessing step 26 and any further 

30 processing steps, the pass state 1008 may be reached. Online issuance of a 
digital certificate 902 or other authentication may ensue. However, if the 



WO 99/60482 PCT/US99/1 1114 

33 

remote authentication object 1004 determines that the user's score lies between 
those designated for a pass state 1008 and a failure state 1018, the remote 
authentication object may offer an offline authentication state 1010, in which 
verification is transmitted using regular mail. 
5 In this condition, offline authentication state 1010 invokes mailability 

filter 1012, which tests for matches on first initial, last name, a house number 
and zip code from at least one address database, as well as consistency of age 
and year of birth and a social security number which is either valid or shows no 
more than a small number of digit transpositions. Other criteria may be applied. 

10 If a sufficient score is reached in the mailability filter 1012 processing, a 

mail state 1014 is reached in which the entered addressing information is used 
to transmit a PIN or other identification information to the user via regular mail. 
If a sufficient score is not reached in the mailability filter 1012, a failure state 
1016 is reached, no verification is sent by mail and processing terminates. 

15 If a user fails to supply a social security number, as illustrated in Fig. 42 

control is passed to remote authentication object 1006, which may apply the 
preprocessing step 26 and further steps to test inputted user information. If the 
inputted user information does not reach a predetermined threshold, control 
passes to a failure state 1022. If a sufficient authentication score is reached, 

20 processing proceeds to offline authentication object 1020. Offline 
authentication object 1020 invokes mailability filter 1024 which processes the 
user-supplied input without a social security number to determine whether 
address standardization, age-related, address-related, or fraud flags are present. 
If a sufficient authentication score is reached in mailability filter 1024, control 

25 passes to the mail state 1026, in which a valid identification PIN is transmitted 
to the user at the entered address using regular mail. Conversely, if mailability 
filter 1024 is not satisfied, a failure state 1028 is reached in which no material is 
mailed and processing terminates. 

An embodiment of the remote authentication system 1002 is illustrated 

30 in more detail in Fig. 43, in which a social security supply object 1030 tests 
whether the user is capable of providing a social security number field. If the 
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user is capable of providing a social security number field, control proceeds to 
pass test module 1032, which may perform preprocessing step 26, first level 
authentication step 32, second level authentication step 40 or other processing. 
If the user passes those levels of authentication with a sufficient score, control 
5 passes to an earned icon state 1034, providing the user with an online 
authentication icon, digital certificate 902 or other issued verification. 

If the pass test module 1032 is not passed, a fatal error object 1036 may 
test for fatal errors in social security, address, age-related or other desired data 
fields. If fatal error object 1036 does not detect a fatal error, control passes to a 

10 mailability filter 1038 which tests for mailability using zip code and state, name, 
deliverability and other field checks, after which a mail state 1040 is entered if 
the user has successfully established reliable information. After mail state 1040 
is entered, both the PIN may be mailed via regular mail and a user icon issued in 
earned icon state 1042. Conversely, if either the fatal error object 1036 or 

15 mailability filter 1 038 are not satisfied with the information the user has entered, 
a failure state 1044 is entered, and processing ends without transmitting an ID 
via mail or an icon being issued. 

As illustrated in Fig. 44, alternatively if the user is not capable of 
supplying a social security number to social security test object 1030, then 

20 control passes to fatal error object 1046. If no fatal error is detected by fatal 
error object 1046, control is passed to mailability filter 1048, which tests for 
deliverable mailing information, as above. If mailability filter 1048 is satisfied, 
the mail state 1050 is reached in which a regular PIN identification is mailed via 
mail to the user, after which an earned icon state 1052 is reached, issuing the 

25 user an online icon identification. Conversely, if either the fatal error object 
1046 or mailability filter 1048 are not satisfied, a failure state 1054 is reached, 
and processing ends. 

The foregoing description of the authentication system and method of 
the invention is illustrative, and variations in construction and implementation 

30 will occur to persons skilled in the art. For instance, while the. invention has 
been generally described as involving a single user supplying authentication 
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information in a single interactive session or alternatively in batch mode, both 
queries and user input may be provided at different times using different input 
modes, when the transaction allows. This may be the case for instance when the 
transaction involves setting up an online subscription to publications or services. 
5 For further example, while the invention has been described in a 

client/server environment in which a user initiates a transaction using a personal 
computer or other device over a computer network, the user could initiate the 
transaction over other networks. The user for instance could conduct a 
transaction using a cellular telephone equipped with an alphanumeric display 

10 which permits the user to keypad data in over the mobile cellular network. 

For yet further example, while the invention has been illustrated in terms 
of an individual consumer initiating a network transaction, the invention can 
also verify the identity of other entities such as corporations, schools, 
government units and others seeking to transact business over a network. Those 

15 entities can be international in nature. The scope of the invention is accordingly 
intended to be limited only by the following claims. 
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Chums 

1. A method of authenticating a network user, comprising: 

a) performing a first authentication step based on a first type of 
information; 

b) performing at least a second authentication step based on a 
second type of information other than the first type of user 
identification information; and 

c) determining based on steps (a) and (b) whether to issue a digital 
certificate. 

2. The method of claim 1 , wherein step (a) comprises: 

i) obtaining the first type of information from the user; 

ii) retrieving user identification information from a data 
source; 

iii) comparing the first type of information supplied by the 
user with the user identification information retrieved 
from the data source; and 

iv) determining a level of correspondence between the first 
type of information supplied by the user and the user 
identification information retrieved from the data source. 

3. The method of claim 2, wherein the data source comprises a credit file of 
the user. 

4. The method of claim 1, wherein step (b) comprises: 

i) determining an availability of the second type of 
information for the user; 

ii) formulating at least one query based on available second 
type information for the user; 

iii) presenting the at least one query to the user for response; 
and 

iv) evaluating the response. 
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5. The method of claim 4, wherein the identity of the user is authenticated 
based on the level of correspondence determined in step (a)(iv) and the 
evaluation made in step (b)(iv). 

6. The method of claim 2, further comprising: 

5 d) determining, based at least in part on the level of correspondence 

determined in step (a)(iv), to: 

i) authenticate the user; . . 

ii) perform at least the second authentication step; 

iii) request additional information from the user; or 
10 iv) take other action. 

7. The method of claim 6, wherein the step (d) of determining is further 
based on a level of certainty of authentication desired. 

8. The method of claim 1, wherein at least one of step (a) and step (b) 
comprises generating an interactive queiy. 

15 9. The method of claim 8, wherein the interactive query comprises at least 
one question having multiple choice answers. 

10. The method of claim 1, further comprising (e) preprocessing 
information supplied by the user. 

1 1 . The method of claim 1 0, wherein the step (e) of preprocessing comprises 
20 at least one of: 

i) standardizing at least one field of information; 

ii) formatting at least one field of information; 

iii) checking internal consistency between at least two fields 
of information; and 

25 iv) checking the validity of at least one field of information. 

12. The method of claim 1 1, wherein based on the step (e) of preprocessing, 
the authentication process determines that: 

i) the user can not be authenticated; 

ii) the user can be authenticated; 

30 iii) the second authentication step should be performed; or 
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iv) manual intervention is required before making an 
authentication determination. 

13. The method of claim 1, wherein the first type of information comprises 
wallet-type information and the second type of information comprises 
non-wallet type information. 

14. The method of claim 1, wherein the second type of information 
comprises information pertaining to credit accounts to which the user is 
a party. 

15. The method of claim 14, wherein the second type of information 
comprises mortgage loan information, and the user is requested to 
identify at least one of: 

a) mortgage lender information; and 

b) mortgage loan amount information. 

16. The method of claim 2, wherein the data source is used to identify the 
15 availability of the second type of information for the user. 

17. The method of claim 1, further comprising (f) receiving biometric input 
from the user. 

1 8. The method of claim 1 , wherein the network comprises the Internet. 

19. The method of claim 1, further comprising (g) logging a transaction 
20 record of the authentication. 

20. The method of claim 1, further comprising (h) executing a pattern 
recognition process to detect potential irregularities in the information 
supplied by the user. 

21 . The method of claim 1 , wherein the digital certificate comprises levels 
25 corresponding to results of the authentication. 

22. The method of claim 1 , wherein the digital certificate comprises user 
identification information, issuer identification information and 
expiration information. 

23. The method of claim 1 , further comprising (i) generating an interactive 
30 query requesting digital certificate information. 
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24. The method of claim 3, wherein the step (c) of generating comprises 
encoding the digital certificate with password information. 

25. The method of claim 1 , further comprising (j) storing the digital 
certificate. 

5 26. The method of claim 1 , further comprising (k) performing an offline 
authentication based upon at least one of the first type of information 
and the second type of information. 

27. The method of claim 26, wherein the step (k) of performing an offline 
authentication comprises applying a mailability filter to at least one of 

10 the first type of information and the second type of information. 

28. A system for authenticating a network user, comprising: 
an input interface for receiving input from the user; 

a processor, connected to the input interface and configured to: 

perform a first authentication based on a first type of 
15 information; 

perform at least a second authentication based on a 
second type of information other than the first type of 
information; and 

determine whether to issue a digital certificate based on 
20 the first authentication and second authentication. 

29. The system of claim 28, wherein the first authentication performed by 
the processor comprises: 

obtaining the first type of information from the user; 
retrieving user identification information from a data source; 
25 comparing the first type of information supplied by the user with 

the user identification information retrieved from the data source; 
and 

determining a level of correspondence between the first type of 
information supplied by the user and the user identification 
30 information retrieved from the data source. 
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30. The system of claim 29, wherein the data source comprises a credit file 
of the user. 

3 1 . The system of claim 28, wherein the second authentication performed by 
the processor comprises: 

5 determining an availability of the second type of information for 

the user; 

formulating at least one query based on available second type 
information for the user; 

presenting the at least one query to the user for response; and 
10 evaluating the response. 

32. The system of claim 3 1 , wherein the identity of the user is authenticated 
based on the level of correspondence determined in the determining and 
the evaluating performed by the processor. 

33. The system of claim 29, wherein the processor determines, based at least 
15 in part on the level of correspondence, whether to: 

authenticate the user; 

perform at least the second authentication; 
request additional information from the user; or 
take other action. ^ 

20 34. The system of claim 33, wherein the determining is further based on a 
level of certainty of authentication desired. 

35. The system of claim 28, wherein the processor generates an interactive 
query. 

36. The system of claim 35, wherein the interactive query comprises at least 
25 one question having multiple choice answers. 

37. The system of claim 28, wherein the processor preprocesses information 
supplied by the user. 

38. The system of claim 37, wherein the preprocessing comprises at least 
one of: 

30 standardizing at ledSt one field of information; 

formatting at least one field of information; 
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checking internal consistency between at least two fields of 
information; and 

checking the validity of at least one field of information. 

39. The system of claim 38, wherein based on the preprocessing, the 
5 processor determines that: 

the user can not be authenticated; 
the user can be authenticated; 

the second authentication step should be performed; or 
manual intervention is required before making an authentication 
10 determination. 

40. The system of claim 28, wherein the first type of information comprises 
wallet-type information and the second type of information comprises 
non-wallet type information. 

41. The system of claim 28, wherein the second type of information 
15 comprises information pertaining to credit accounts to which the user is 

a party. 

42. The system of claim 41, wherein the second type of information 
comprises mortgage loan information, and the query comprises a request 
for the user to identify at least one of: 

20 mortgage lender information; and 

mortgage loan amount information. 

43. The system of claim 29, wherein the data source for the first type of 
information is used to identify the availability of the second type of 
information for the user. 

25 44. The system of claim 28, wherein the processor receives biometric input 
from the user. 

45. The system of claim 28, wherein the network comprises the Internet. 

46. The system of claim 28, wherein the processor logs a transaction record 
of the authentication. 
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47. The system of claim 28, wherein the processor executes a pattern 
recognition process to detect potential irregularities in the information 
supplied by the user. 

48. The system of claim 28, wherein the digital certificate comprises levels 
5 corresponding to results of the authentication. 

49. The system of claim 28, wherein the digital certificate comprises user 
identification information, issuer identification and expiration 
information. 

50. The system of claim 28, wherein the processor generates an interactive 
10 query requesting digital certificate information. 

51. The system of claim 50 wherein the processor encodes the digital 
certificate with password information. 

52. The system of claim 28, wherein the processor stores the digital 
certificate. 

15 53. The system of claim 28, wherein the processor performs an offline 
authentication based on at least one of the first type of information and 
the second type of information. 
54. The system of claim 53, wherein the offline authentication comprises 
applying a mailability filter to the at least one of the first type of 

20 information and the second type of information. 
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TRANSACTION DATA REQUIRED FOR TRANSACTION LOGS 



112 

/ 



TRANSACTION ID 



TRANS NO. 



CUSTOMER NO. 



CONSUMER ID 



DATE/TIME 



APPUCATION INFORMATION* 


LAST NAME 




FIRST NAME 




MIDDLE NAME OR INITIAL 




SUFFIX 




MAIDEN NAME 




CURRENT ADDRESS - LINE 1 




CURRENT ADDRESS - LINE 2 




CURRENT ADDRESS- COUNTY 




CURRENT ADDRESS • CITY 




CURRENT ADDRESS- STATE 




CURRENT ADDRESS -ZIP CODE 




AT CA< 2 YEARS INDICATOR 




FORMER ADDRESS- LINE 1 




FORMER ADDRESS -LINE 2 




FORMER ADDRESS -COUNTY 




FORMER ADDRESS -CITY 




FORMER ADDRESS- STATE 




FORMER ADDRESS- ZIP CODE 




HOME PHONE NUMBER 




HOME PHONE > 4 MOS OLD INDICATOR 




AREA CODE CHANGE INDICATOR 




HOME PHONE PUB INDICATOR 




WORK PHONE NUMBER 




WORK PHONE EXTENSION 




GENDER 




DATE OF BIRTH 




SOCIAL SECURITY NUMBER 




DRIVERS LICENSE ISSUED INDICATOR 




DRIVERS LICENSE NUMBER 




DRIVERS LICENSE STATE OF ISSUE 




DL ADDRESS * CA OR FA INDICATOR 




DLADDRESS-LINE1 




DLADDRESS-LINE2 




DLADDRESS-CITY 




DL ADDRESS- STATE 




DL ADDRESS -ZIP CODE 




APPLICATION INFORMATION (CONTINUED) 
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MOTHER'S MAIDEN NAME 




YEAR OF HIGH SCHOOL GRADUATION 




NUMBER OF SIBLINGS 




E-MAIL ADDRESS 





112 



'INFORMATION RECEIVED ON THE APPLICATION WILL BE STORED EXACTLY AS PROVIDED 
BY THE CONSUMER ON THE APPLICATION FORM. 



PROCESS^ 

PROCESS COMPONENT 


G RESULTS 


PROCESS STATUS CODE 




PROCESS SCORE 




DATE/TIME 





VALID PROCESS COMPONENTS 
SSN VALIDATION 


VALID PROCESS SCORES 
PASS, FAIL 


ADDRESS VALIDATION 


P.F 


AREA CODE VALIDATION 


P.F 


DRIVER'S LICENSE FORMAT VALIDATION 


P.F 


ACRO ID COMPARE 


BIG, REGULAR, POSSIBLE, NO HIT 


METROMAIL ID COMPARE 


B.R.P.N 


DRIVERS LICENSE ID COMPARE 


B.R.P.N 


CUSTOMER LIST ID COMPARE 


B.R.P.N 


TRADE LINE TEST 


B.R.P.N 


MANUAL EVALUATION 


B.R.P.N 


ID DECISION ~ ~ 


B,R,P,N 



VAU 

STATUS CODE 
NOTASSIGNED 


D PROCESS STATUS CODES 

DESCRIPTION 
PROCESS COMPLETE 


NOTASSIGNED 


PROCESS COMPLETE - FLAGGED FOR MANUAL 


NOTASSIGNED 


ABORTED -COMM ERROR 


NOTASSIGNED 


ABORTED -SYSTEM ERROR 


NOTASSIGNED 


ABORTED -SENTTO MANUAL 



















SSN VALID* 

SSN EDIT CHECKS 


WON DATA 

PASS, FAIL, NOT INVOKED 


SSN ISSUED CHECK 


P.F.N 


SSN DECEASED 


P.F.N 


SSN FRAUD 


P.F.N 


TABLE VERSION NO(S) 
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P0STALS0FT OUTPUT 

OUTPUT ADDRESS 

STATUS OR ERROR CODE 

RECORD TYPE 

DIRECTORY VERSION 

PROGRAM VERSION 



ACRO ID CO 

Til EC DCTI IDMCn 


unAoc n ATA 

WARE DATA 
0,1,2, 3,4 


cdai in VICTIM 
rrv\UU vll» l IM 


Y,N 


oArtoOAIM UUUt 




LyU bcAKOn oUORc 




CHOICEPOINJ DRIVERS L 
CP # OF CANDIDATES RETURNED 
CPP151 CLASSIFICATION 


CENSE ID COMPARE DATA 
RS = REPORT SUBJECT 


CP NAME -LAST 




CP NAME - FIRST 




CP NAME -MIDDLE 




CP NAME -SUFFIX 




CP DATE OF BIRTH 




CP GENDER 




CPSSN 




CP FSI- NAME- LAST 


MATCH, DISCREPANCY, BLANK 


CP FSI- NAME -FIRST 


M,D, BLANK 


CP FSI- NAME -MIDDLE 


M,D, BLANK 


CP FSI -NAME -SUFFIX 


M, D, BLANK 


CP FSI -DATE OF BIRTH 


M,D, BLANK 


CP FSI -GENDER 


M,D, BLANK 


CPFSI-SSN 


M,D, BLANK 


CPDL51 CLASSIFICATION 


CP = CURRENT PERSONAL 
CL = CURRENT LEARNER'S PERMIT 
CC = CURRENT COMMERCIAL 
PP= PREVIOUS PERSONAL 
PC = PREVIOUS COMMERCIAL 


CP DRIVER'S LICENSE NUMBER 




CP DRIVER'S LICENSE STATE 




CP FSI -DRIVER'S LICENSE NBR 


M, D, BLANK 


CP FSI -DRIVER'S LICENSE STATE 


M, D, BLANK 


CP DRIVER'S LICENSE EXPIRATION 
DATE 


POSSIBLE FUTURE ENHANCEMENT 


CP DRIVER'S LICENSE ISSUE 
DATE 


POSSIBLE FUTURE ENHANCEMENT 


CP AL51 CLASSIFICATION 


RA= RESIDENCE ADDRESS 
FA = FORMER ADDRESS 


CP ADDRESS- HOUSE NUMBER 




CHOICtFUINI DRIVER'S LICENSED COMPARE DATA (CONT) 



FIG. 15 
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CP ADDRESS - STREET NAME 




CP ADDRESS -APARTMENT 
NUMBER 




CP ADDRESS -CITY 




CP ADDRESS -STATE 




CP ADDRESS -ZIP 




CPADDRESS-ZIP CODE + 4 




CP FSI -ADDRESS -HOUSE 
NUMBER 


M, D, BLANK 


CP FSI -ADDRESS -STREET 
NAME 


M, D, BLANK 


CP FSI -ADDRESS -APT NUMBER 


M,D, BLANK 


CP FSI -ADDRESS -CITY 


M,D, BLANK 


CP FSI -ADDRESS -STATE 


M, D, BLANK 


CP FSI -ADDRESS -ZIP CODE 


M,D, BLANK 


CP FSI -ADDRESS -ZIP CODE +4 


M, D, BLANK 


*CP = CHOICEPOINT 



112- 



METROMETIDCOMPA 

MN NAME 


RE DATA 


MN ADDRESS 




MN PHONE NUMBER 




MN PRIMARY RESPONSE CODE 




MN NM/ADD VERIFICATION RESPONSE CODE 




MN PHONE VERIFICATION RESPONSE CODE 




MNEDAREQUEST 


Y,N " 


MN EDA REQUEST CONFIDENCE CODE 


NULL. IF EDA CHECK = 'N' 


* MN = METRONET 



TRADE TYPE 
DATE OPENED 



M,A,P,S,G 



LENDER NAME 

LENDER - MULTIPLE CHOICE OPTIONS 7 



LENDER • CONSUMER RESP ONSE 
TERMS OR MONTHLY PMT 



TERMS OR MONTHLY PMT • MC OPTIONS' 
TERMS OR MONTHLY PMT • CONSUMERRESP 



* rnJlIKElPxK 0 ^ SH0ULD BE STORED IN THE ORDER PRESENTED TO THE 
CONSUMER AND WITH THE CORRECT RESPONSE INCLUDED. 
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REASONING 


ON 2ND ATTEMPT, RECOGNIZE THE 
CONSUMER HAS VISITED US ONCE 
BEFORE AND DISPLAY THE SAME 
QILT. POSSIBLE FRAUD: GREATER THAN 
2 ATTEMPTS FOR SAME CONSUMER 


SAME PERSON MAYRE-ENTER APPLICATION; 
POSSIBLE FRAUD: ODDS OF MULTIPLE ATTEMPTS 
WITHIN SPECIFIED TIME FRAME THRU DIFFERENT 
CUSTOMERS FROM SAME E-MAIL ADDRESS ARE 
UNLIKELY • EXCEPT FOR SPOUSES (CHILDREN OVER 
18 PROBABLY HAVE DIFFERENT E-MAIL ADDRESSES). 


— — ' 

SAME PERSON MAYRE-ENTER APPLICATION; POSSIBLE 
FRAUD: ODDS OFMULTIPLEATTEMPTS WITHIN 
SPECIFIEDTIME FRAMETHRU SAME CUSTOMER 
FROM SAME E-MAILADDRESS ARE UNLIKELY- EXCEPT 
FOR SPOUSES. CUSTOMERS SHOULD USE SPECIAL 
ACCESS ID AFTER RCA COMPLETED ONCE 


FRAUD (AND POSSIBLY HOSTILE ATTACK?) 
: SOMEONE KNOWS LAST NAME, AND POSSIBLY 
ADDRESS, CHANGES FIRSTNAME, SSN, AND/OR 
DOB TO 'STEAL IDENTITY 1 




i 


= 




IF SAME FIRST NAME AND SAME LAST 
NAMEANDSAMESSNANDSAME 
DOB -> OK; ELSE IF DIFFERENT FIRST 
NAMEORDIFFERENTLASTNAMEOR 
DIFFERENTSSN OR DIFFERENT 
DOB -> POSSIBLE FRAUD RECOGNIZED 


IF SAME FIRSTNAMEAND SAME LAST 
NAMEANDSAMESSNANDSAME 
DOB -> OK; ELSE IF DIFFERENT FIRST 
NAMEORDIFFERENTLASTNAMEOR 
DIFFERENTSSN OR DIFFERENT 
DOB •> POSSIBLE FRAUD RECOGNIZED 


IF SAME FIRSTNAMEAND SAME SSN 
AND SAME DOB •> OK; ELSE IF 
DIFFERENTFIRST NAME OR DIFFERENT 
SSN OR DIFFERENT DOB -> POSSIBLE 
FRAUDRECOGNIZEO 


CD 

Li. 


TIME CDAUC 


GREATER 
THAN 2 
ATTEMPTS 
WITHIN 72 
HOURS 


GREATER 
THAN 2 
ATTEMPTS 
WITHIN 72 : 
HOURS 


GREATER 
THAN 2 
ATTEMPTS i 

m i i_iYii i u 

WITHIN 60 
HOURS 


GREATER 
THAN 2 
ATTEMPTS 
WITHIN 72 
HOURS 


FIELDS IN 
WHICH 
MATCH IS 
IRRELEVANT 


STRNUM, 
CITY, STATE, 
ZIP, E-MAIL 
ADDRESS, IP 
ADDRESS, 
HOMEPHONE 
NUMBER 


STRNUM, 
CITY, STATE, 
ZIP, IP 
ADDRESS, 
HOMEPHONE 
NUMBER 


STRNUM, 
CITY, STATE, 
ZIP, IP 
ADDRESS, 
HOMEPHONE 
NUMBER 


STRNUM, 
CITY, STATE, 
ZIP, IP 
ADDRESS, 
HOMEPHONE 
NUMBER 


FIELDS 

NOT 

EQUAL 










FIELDS MATCHED 


LASTNAME, 
RRSTNAME, 
SSN, DOB, 
VALID SSN 
FLAG 


E-MAILADDRESS 

MAI unto 


E-MAILADDRESS 
MATCHES 


lASTNAME, 
IP ADDRESS 
MAI Onto 


PATTERN 

RECOGNITION 

CODE 






LU 




U 
ZI 

c 


J 

5 


SAME 

CONSUMER 


SAMEE-MAIL 

ADDRESS/ 

DIFFERENT 

PI ICTAMCD 

lUolUMtK 


SAMEE-MAIL 

ADDRESS/SAME 

CUSTOMER 


SAME LAST 

ii a i ir* 

NAME 
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FRAUD: SOMEONE STEALING INFOABOUT 
ANOTHER, BUTUSING OWN ADDRESS FOR MAILING 
PURPOSES, TRYING VARIOUS LAST NAMES 


FRAUD: SOMEONE STEALING INFO ABOUT 
ANOTHER, BUTUSING OWN ADDRESS FOR MAILING 
PURPOSES, TRYING VARIOUS SSNs 


ON 2ND ATTEMPT, RECOGNIZE THE CONSUMER HAS 
VISITED US ONCE BEFORE AND DISPLAY THE SAME 
QILT. POSSIBLE FRAUD: GREATER .THAN 2 ATTEMPTS 
FOR SAME CONSUMER. 


POSSIBLE HOSTILE ATTACK • SOMEONE VARYING 
PIECE OF APPLICATION INFORMATION • SIMILAR 
TO ATTEMPTS FOR ACRO FILES (PER JIM 
DIFFENBAUGH) 










GREATER 
THAN 2 
ATTEMPTS 

WITHIN 7? 
ivi i mil ic 

HOURS 


GREATER 
THAN 2 
ATTEMPTS 
WITHIN 72 

1(111 III 1 t Im 

HOURS 


GREATER 
THAN 2 
ATTEMPTS 
WITHIN 72 
HOURS 


GREATER 
THAN 2 
ATTEMPTS 
WITHIN24 
HOURS 


FIRSTNAME, 
DOB, HOME 
PHONE 
NUMBER 








1 LU 

31 






LAST 
NAME 


STR NUM. CITY, 
STATE, ZIP, SSN, 
VALID SSN 
FLAGALL MATCH 


STR NUM. CITY, 
STATE, ZIP, LAST 
NAME, VALID SSN 
FLAG ALL MATCH 


LAST NAME, 
FIRSTNAME, 
IP ADDRESS, 
SSN, DOB, E-MAIL, 
STATE, ZIPALL 
MATCH 


IP ADDRESS, 
FIRSTNAME, 
MIDDLE, 
LAST NAME, 
SUFFIX, E-MAIL 
ADDRESS, STR 
NUMBER, STREET 
NAME, STREET 
TYPE, CITY, STATE, 
ZIP, SSN, HOME 
PHONE, DOB, SSN 
VALID FLAG ALL 
THE MATCH 


CO 




X 




SAME 

ADDR&SSN 


SAMEADDR 
& LAST NAME 


6 FOR 6 


SAME 

APPLICATION 



co 
CD 
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MATCH NAME 


NUMBER OF SESSIONS 
(RETURNED FROM 
PATTERN RECOGNITION) 


ACTION 


CAME rOMCI IMCD 


0 


NEWQILT 


SAME CONSUMER 


1 


PREVIOUS QILT 


OAMC fV\MQI IMCD 

oAMt OUNoUMER 


w A 

>1 


SUSPECTED FRAUD: LOCK OUT 


SAME E-MAIL/DIFFERENT 

OUolUIVicrvUlrrcKtm OUNoUIVItK 


0 


NEWQILT 


SAME E-MAIL/DIFFERENT 

PI IQTnMPD/niPCCDCMT PflMOl IMCD 
Uuo I UMcrvUlrrtKtlN I uUINoUlvltK 


1 , 


NEWQILT 


SAME E-MAIL/DIFFERENT 

OUolUMfcK/UlrrtKbNI UUNbUMER 


>1 


SUSPECTED FRAUD: LOCK OUT 


SAME E-MAIL/SAME 

PI ICTHMCD/niCCCDCMT PAAIOI WACO 

WJolUMtK/ulrrtKtNl UUNoUlvlER 


0 


NEWQILT 


SAME E-MAIL/SAME 

pi iQTnycD/nicccDCMT phmci llACB 
UJo lUMtK/UlrrtKtNl OUNoUMER 


1 


NEWQILT 


SAME E-MAIL/SAME 

PI IQTPlUED/niCCCDCMT PAMOI IMCD 


>1 


SUSPECTED FRAUD: LOCK OUT 


SAME LAST NAME/SAME IP 

AIY1RFQQ 


0 


NEWQILT 


SAME LAST NAME/SAME IP 

MUUiauOo 


1 - J 


NEWQILT 


SAME LAST NAME/SAME IP 

AnnRFQC 
nULmCOO 


>1 


SUSPECTED FRAUD: LOCK OUT 


SAMEADDRESS/SAME 

^N/niFFFRFMT 1 AQT MAMF 
ooiwuirrcrvciN 1 LAO 1 INnlVIt 


0 


NEWQILT 


SAMEADDRESS/SAME 
SSN/DIFFFRFNT 1 A9T MAMF 


1 


NEWQILT 


QAMF AnnDFCQ/CAMC 
OMJVIC nUUKtoo/oAIVit 

SSN/DIFFFRFNT 1 A<?T MAMF 


>1 


SUSPECTED FRAUD: LOCKOUT 


<\AMF AnnRFQQ/niFFCDCMT 

SSN/SAME LAST NAMF 


ft 

0 


NEWQILT 


^AMF AnnRFQQ/niFFFRFMT 
OnlvlL nUUrvCOO/UlrrurvClN 1 

SSN/SAME LAST NAME i 


1 


k 1 if /Nil ^ 

NEWQILT ; 


SAME ADDRESS/DIFFERENT 
SSN/SAME LAST NAME 


>1 


SUSPECTED FRAUD: LOCK OUT 


6 FOR 6 


0 


NEWQILT 


6 FOR 6 


1 


NEWQILT 


6 FOR 6 


>1 


SUSPECTED FRAUD: LOCK OUT 


SAME APPLICATION 


0 


NEWQILT 


SAME APPLICATION 


1 


NEWQILT 


SAME APPLICATION 


>1 


SUSPECTED FRAUD: LOCK OUT 
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E TEST POINT ASSIGNMENT MATRIX FOR TRADE TYPES 
(EXAMPLE) 


I MAX ALLOWABLE 
CERTAINTY SCORE 


CD 
CD 


CD 
CD 


CD 
CD 


CD 
CD 


CD 
CD 


CD 
CD 


CD 
CD 


CD 
CD 


CD 
CD 


CD 

en 


CD 
CO 


CD 

cr> 


CD 

cr> 


CD 

r — 


CD 
CO 


CD 
CO 


CD 
CO 


CD 
CO 


CD 
CO 


CD 


CD 
LO 


CD 


CD 


CD 
CO 


CD 


GAS CARD 
QUESTION 






CD 




CD 


CD 




CD 


CD 


CD 








CD 






CD 




CD 


CD 










CD 


STUDENT LOAN 
QUESTION(S) 




CD 
eg 




CD 
CNI 




CD 
CO 


CD 
CO 




CD 
CO 


CD 
CO 






CD 
CO 






CD 
CO 




CD 
CO 




CD 
CO 








CD 
CO 




INSTALLMENT LOAN 
QUESTION(S) 


LO 
CVI 






CD 
CO 


CD 

-^r 




S3 


to 




CD 
LO 




CD 






LO 






CD 
LO 


CD 
LO 








CD 






TRADE LIN 


AUTO LOAN 
QUESTION(S) 


LO 
CVI 


CD 
CO 


CD 








LO 
CO 


LO 


CD 
LO 




CD 








LO 


CD 
LO 












CD 










MORTGAGE LOAN 
QUESTION(S) 


CD 
LO 


CD 
LO 


CD 
LO 


CD 
LO 


CD 
LO 


CD 
CO 










CD 
LO 


CD 
LO 


CD 
CO 


CD 
CO 














CD 
LO 











CO 

o 

CO 



o 

CM 
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CO 
LU 
Q_ 

SI 
O 
\— 
CO 
LU 
ZD 

o 
ce 
o 

u_ 

>< 



CD 
CO 
CO 

<: 



CD 



CO 



LU 
Q 



O 
h— 
CO 
LU 
Z> 

O 
Q 

O 
O 
LU 
CO 

O 



CO 
LU 
ZD 
O 
CO 

en 



. o 

co 



UD 
CSJ 



CO 
LU 



cr 

LU 
Q 

LU 



Q< 

co ^ 
goo 

LUZD 
CO o 

UJCO 

r> LLI 



CM 



il 05 

ace 

§2 

as 

CD 

r— LU 

£££ 

LU 

S^o 

C^COLU 
Oil — ii i 

q or 
ceo 

Egg 















LU 

1 

Q_ 


CD 


































LU, 












h— 


ce 

LU 










CO 


CO 




CL. 
















LU 


























US 










TRADE 


o 






















o 












U_ 












X 














LU 










1 


CO 












TYS 


o 

CD 


3 


cn 

CO 


o> 


lvn 




LO 
CO 


CD 


CD 


CD 


HQ 


a: 

LU 










MATC 


O 











-CD 
CO 



CSI 
CNJ 

CD 
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PROC 


ESS RESULTS 


1 CERTAINTY SCORE 


ACRO 


METRONET 


CHOICEPOINT 


TRADE LINE TEST 
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B " ~ 
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100 
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B 


86 

WW 




R 


B 


P 


B 


86 

UU 




B 


R 


N 


B 


85 

WW 




B 


P 


B 


B 


Uw 




R 


B 


N 


B 


as 




R 


R 


R 


B 


85 

Uw 




P 


B 


B 


B 


85 

Uw 




R 


R 


P 


B 


81 

U 1 




"B~ 


B 


B 


R 


80 




B 


T~ , 


R 


B 


80 




B 


N 


B 


B 


80 




R 


"R 


N , 


B 


80 




R 


P 


B 




80 

WW 




P 


B 


R 


B 


80 

WW 




P 


R 


B 


B 


80 




B 


P 


P 


B 


76 




P 


B 


P 


B 


76 

I w 




B 


B 


~R~ 


R 


75 




B 


R 


B 


R 


75 




B 


P 


N 


B 


75 




B 


N 


R 


B 


75 




R 


B 


"1 


K 


75 




R 


P 


R 


B 


75 




R 


N 


B 


B 


75 




P 


B 


N 


B 


75 




P 
K 


R 


R 


B 


75 




B 

T5 


B 


P 


K 


71 




B 


N 


P 


6 


71 




D 

i\ 


t> 
r 


T5 

r 


B 

B 


71 




P 


R 


p 


B 


71 




6 


B 


N 


K 


70 




B 


ft 


R 


K 


70 




B 


N 


N 


B 


70 




R 


B 


R 


R 


70 




R 


R 


B 


R 


70 




R 


P 


N 


B 


70 




R 


N 


R 


B 


70 




P 


R 


N 


B 


70 




P 


P 


B 


B 


70 




B 


R 


P 


R 


66 





FIG. 23 

SUBSTITUTE SHEET (RULE 26) 



WO 99/60482 



21/37 



PCT/US99/I1114 



PROC 


ESS RESULTS 


1 CERTAINTY SCORE 


ACRO 


METRONET 


CHOICEPOINT 


TRADE LINE TEST 
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CERTAINTY SCORES FOR ID DECISIONING" 



PROCESS RESULTS 


i CERTAINTY SCORE 


ACRO 


METRONET 


CHOICEPOINT 


TRADE LINE TEST 
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EQUIFAX 



IDENTITY VERIFICATION CENTER 



f 



INTERACTIVE QUERY 



TO APPLY FOR YOUR DIGITAL CERTIFICATE, YOU MUST ENTER THE INFORMATION REQUESTED BELOW 
REQUIRED FIELDS ARE BOLD. 

PERSONAL IDENTIFICATION INFORMATION 
YOUR NAME 



FIRST PAUL 



MIDDLE M 



LAST | BENTON 
SUFFIX 



GENDER OFEMALE 



SOCIAL SECURITY NUMBER 1222-01-4141 



DATE OF BIRTH MONTH [O30 DAY [07 

MAIDEN NAME | 
(IF APPLICABLE) 



YEAR 1959 



E-MAILADDRESS ljsmith@abcdefg.conT 



(REENTER FOR | ismith@abcde fq.conT 
CONFIRMATION) 



CURRENT ADDRESS 



ADDRESS 1 3199 BARRACK DRIVE" 
LINE 2 



CITY IALPHARETTA" 
STATE [GA 



ZIP 30202 



COUNTY/PARISH HrOlTON 



TIME AT CURRENT | LESS THAN 2 YEAR S 
ADDRESS 

FORMER ADDRESS 

(REQUIRED IF CURRENT ADDRESS LESS THAN 2 YEARS) 



FIG. 31 
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ADDRESS 1 8544 FULTON INDUSTRIAL BLVD 
LINE 2 



CITY ATLANTA 



STATE GA 



ZIP 30396 



COUNTY/PARISH FULTON 



PHONE NUMBER INFORMATION 

PHONE NUMBERS MAY BE FORMATTED (nnn) nnn - nnnn,ornnn-nnn-nnnn, OR n 



HOME PHONE NUMBER 1(770)592 - 3673 



HAS THE AREA CODE OF YOUR HOME PHONE [NO 
NUMBER CHANGED IN THE LAST 6 MONTHS? 



HAVE YOU HAD YOUR CURRENT HOME PHONE [YES 
NUMBER FOR MORE THAN 4 MONTHS? 



IS YOUR HOME PHONE NUMBER PUBLISHED? [YES 
WORK PHONE NUMBER I 



EXTENSION [ 



DRIVER'S LICENSE INFORMATION 
DO YOU HAVE OR HAVE YOU EVER HAD A DRIVER'S LICENSE? ovFS 
(NUMBER AND STATE REQUIRED IF YES) o NO 
DRIVER'S LICENSE NUMBER [B36492014 



STATE OF ISSUE \GK 



iJSSSIS^^ 8 ° SAME AS CURRENT ADDRESS 
(ADDRESS REQUIRED IF DIFFERENT) o SAME AS FORMER ADDRESS 

©DIFFERENT ADDRESS 

ADDRESS | 
LINE 2 1 

CITY ~ ' ~ " 

STATE 
ZIP 



PLEASE ENTER THE FOLLOWING INFORMATION. 
IT WILL BE USED FOR ADDITIONAL SECURITY. 

FIG. 32 

MOTHER'S MAIDEN NAME 

YEAR OF HIGH SCHOOL GRADUATION (YYYY) 

NUMBER OF SIBLINGS (INCLUDING HALF AND STEP SIBLINGS) 



SUBMIT REQUEST 

FIG. 33 
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EQUIFAX 



"z: 



IDENTITY VERIFICATION CENTER 



I 



INTERACTIVE QUERY 

1. YOUR CREDIT FILE INDICATES YOU MAY HAVE AMORTGAGE LOAN, ON OR 
AROUND AUGUST 1998. PLEASE CHOOSE THE CREDIT PROVIDER FOR THE 
FOLLOWING OPTIONS: 

° BANK OF AMERICA, FSB 
° DARBY BANK & TRUST CO. 
® HEALTH CARE CREDIT UNION 
°IBEW FEDERAL CREDIT UNION 
° NONE OF THE ABOVE 

2. PLEASE CHOOSE THE RANGE WITHIN WHICH YOUR MONTHLY PAYMENT LIES 
FOR THE PREVIOUSLY REFERENCED ACCOUNT. IF YOU MAKE BI-WEEKLY 
PAYMENTS MULTIPLY THE PAYMENT BY 2.17 TO CALCULATE THE MONTHLY 
PAYMENT. 

° $575 -$674 
0 $675 -$774 
® $775 -$874 
° $875 -$974 
° NONE OF THE ABOVE 

3. YOUR CREDIT FILE INDICATES YOU MAY HAVE AN INSTALLMENT ACCOUNT 
SUCH AS BANK LOANS, ELECTRONIC/APPLIANCE ACCOUNTS, JEWELER 
ACCOUNTS, AUTO LOANS OPENED IN OR AROUND NOVEMBER 1994. PLEASE 
CHOOSE THE CREDITOR FOR THIS ACCOUNT FROM THE FOLLOWING OPTIONS: 

0 EXCEL FEDERAL CREDTI UNION 
° HALLMARK FINANCE CO. 
° INDEPENDENT BANK 
° JOE COOPER'S FINANCE CORP. 
° NONE OF THE ABOVE 

FIG. 34 

4. PLEASE CHOOSE THE RANGE WITHIN WHICH YOUR MONTHLY PAYMENT LIES 
FOR THE PREVIOUSLY REFERENCED ACCOUNT. IF YOU MAKE BI-WEEKLY 
PAYMENTS MULTIPLY THE PAYMENT BY 2.17 TO CALCULATE THE MONTHLY 
PAYMENT. 

° $375 -$424 
®$425-$474 
° $475 -$524 
° $525 -4574 
° NONE OF THE ABOVE 



SUBMIT REQUEST 



CANCEL REQUEST 
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EQUIFAX IDENTITY VERIFICATION CENTER 
/ 



INTERACTIVE QUERY 

YOU HAVE BEEN SUCCESSFULLY AUTHENTICATED. 

TO GET YOUR DIGITAL CERTIFICATE, CLICK THE CONTINUE BUTTON. 



CONTINUE 



FIG. 36 



EQUIFAX USER ENROLLMENT 

ENROLLMENT STATUS 

SI a9SHSI?H5 N8E Y0U ENTERED D0ES N0T THE ONE IN OUR RECORDS. 

2SS^^5?^ Y0UR USER ENR °LLMENT. PLEASE ENTER THE CHALLENGE 
RESPONSE EXACTLY AS YOU DID WHEN YOU SUBMITTED YOUR ENROLLMENT REQUEST. 

CHECK USER ENROLLMENT STATUS 

CHALLENGE QUESTION: WHAT IS HASH'S FAVORITE HASH? 

CHALLENGE RESPONSE: |SHA1 1 



CHECK ENROLLMENT STATUS 

FIG. 37 
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EQUIFAX USER ENROLLMENT 



SUBMIT ENROLLMENT REQUEST 

TO ENROLL YOURSELF AND OBTAIN A CERTIFICATE TO ACCESS EQUIFAX'S SECURE NETWORK: 

1. VERIFY AND SUBMITTHE USER ENROLLMENT FORM BELOW. 

2. MAKE SURE YOU ENTER A CHALLENGE QUESTION OF YOUR CHOICE (e.g., "WHAT IS 
THE LAST 4 DIGITS OF YOUR HOME PHONE NUMBER?") AND THE CORRESPONDING 

iSSKSf SSKS (e - 9 ' " 2145 ")' WEU CHECKING Y0UR ENROLLMENT STATUS 
SJS Et R0VIDE ™ E SAME CHALLENGE RESPONSE. UNLIKE ATYPICAL 
SSSHSSSSff 1 ' THE CHALLENGE QUESTION/RESPONSE COMBINATION IS 
SESKS? T0 REC ALL AFTER A LONG PERIOD OF TIME. SINCE THE CHALLENGE 
ESJSFJ CASE-SENSITIVE, YOU MAY WANTTO USE ALL LOWER-CASE OR ALL 
UPPER-CASE LETTERS. 

4 

5 ' AUTOMATICAaY ST B APPR0VH) ' Y0UR CERTIFICATE WILL BE DOWNLOADED 
6. FOLLOW INSTRUCTIONS TO CONFIRM YOUR CERTIFICATE. 

DIRECT USER ENROLLMENT 

FIRST NAME: PAUL 
LAST NAME: BENTON 
E-MAIL ADDRESS: pbenton@mycmpany.com 

CHALLENGE QUESTION: I WHAT IS HASH'S FAVORITE HASH 



CHALLENGE RESPONSE: [SHAT 



VERIFY AND SUBMIT 



EXIT AND RE-AUTHENTICATE I 

FIG. 38 
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EQUIFAX 



CERTIFICATE CENTRAL 



CERTIFICATE CENTRAL IS THE STARTING POINT FOR ACTUAL CERTIFICATE ISSUANCE. 

IF YOU HAVE QUESTIONS ON CERTIFICATE ENROLLMENT, PLEASE READ THE EQUIFAX CERTIFICATE 
ENROLLMENT FREQUENTLYASKED QUESTIONS AND ANSWERS FOR FURTHER INFORMATION. 

WHATBROWSERS ARE SUPPORTED FOR CERTIFICATE ENROLLMENT? 

CERTIFICATE ENROLLMENT SUPPORTS NETSCAPE NAVIGATOR 3.x, NAVIGATOR AND 
COMMUNICATOR 4.x, AND MICROSOFT INTERNET EXPLORER 4jc WITH JAVASCRIPT ENABLED. 



EQUIFAX CERTIFICATE ENROLLMENT 

MR. BENTON, TO REQUEST YOUR CERTIFICATE BASED ON YOUR SUCCESSFUL 
AUTHENTICATION, PRESS THE GO BUTTON. 



GO 



FIG. 39 



l% new User Certificate • netscape - 



J3H2 



NEW USER CERTIFICATE 

YOU HAVE RECEIVED A NEW CERTIFICATE. NAVIGATOR WILL REFER TO THIS 
CERTIFICATE BY THE NAME SHOWN BELOW. YOU CAN USE THE NAME PROVIDED OR 
ENTERANEWONE. 

CLICK OK TO INSTALLTHE CERTIFICATE INTO NAVIGATOR OR CLICK CANCELTO REFUSE 
YOUR NEW CERTIFICATE. 



CERTIFICATE NAME: 



IPAUL BENTON'S EQUIFAX - DEMONSTRATIONF 



CERTIFICATE FOR: PAUL BENTON 



SHOW CERTIFICATE 



0 



MORE INFO 



OK 



CANCEL 



END 
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